1. Field of the Invention
The present invention relates to template-based rule generation. In particular, embodiments of the present invention relate to a framework for template-based rule generation for a rule-based system, such as a rule-based monitoring system.
2. Description of the Related Art
Generally, rule-based systems refer to any kind of system which is configured to process (i.e. handle) their tasks on the basis of specified rules. In this regard, rules designate directives for processing, which may be pre-defined by an operator of the respective rule-based system. Such rule-based systems may be applied to any kind of task or purpose, and they are thus not restricted to any specific kind of application.
For the purpose of illustrating the present invention and its embodiments, network monitoring systems are taken as a non-restrictive example for rule-based systems. Nevertheless, it will be evident that the present invention and its embodiments as set out in the following will be applicable to any kind of rule-based system, such as for example service monitoring systems.
Rule-based network monitoring systems normally process alarms and network performance measurements to conclude on the state of services in communication or information technology (data) networks. The conclusion whether a network service is up or down, or if the service quality is sufficient, is done by so-called monitoring rules consisting of conditions and actions. The rules are checked in terms of their specific conditions on the incoming alarms and measurements, and then executed with the corresponding actions accordingly.
When setting up a network monitoring tool for monitoring services in a network, the administrator has to define the rules according to which problematic situations shall be detected and/or handled in the specific network. This usually involves the definition of error conditions (e.g. an alarm XYZ has been received, a network performance measurement has exceeded a threshold, etc.) and the corresponding actions (e.g. indicate the problem in the monitoring tool, launch a repair script etc.).
In a monitoring system, the typical life-cycle of a monitoring rule starts with the specification, the implementation and testing, and the deployment phases. Depending on the flexibility of the monitoring system the rule implementation can be performed in various ways ranging from simple form-based user interfaces (e.g. definition of simple conditions with thresholds and selection from a limited number of actions) up to flexible, but more complex scripting solutions.
It is to be noted that what is called “rule development” in this specification may also be called “learning phase”, “system fine-tuning”, “system setup phase” or “system configuration” in the context of the different network monitoring tools or other conceivable applications.
Existing network monitoring systems offer the ability to process events or messages (e.g. alarms, network performance measurements) sent by data collectors or agents from some part of the network. The way monitoring rules may be defined depends on the complexity of the required or desired rule. For less complex rules, there are a number of known GUI-driven (GUI: graphical user interface) approaches, while the implementation of complex rule logic requires the knowledge of a programming language, and is a rather cumbersome procedure to be carried out by skilled personnel.
In the following, there is described in more detail what is meant by complex and less complex rules and their typical development phases including testing and documentation.
The least complex and most common form of monitoring rules may be considered to be filtering rules applied on individual events. Important events are identified by threshold or comparison conditions applied on individual fields of the event. The implementation of these types of rules may be supported by form-based user interfaces and does usually not require the knowledge of a programming language. Upon creation, the rules are usually tested by inspecting the result of events sent by simulators with the corresponding event field content. The rules are documented, if necessary, in the network operator's own way and format. That is, the rule creator such as the network operator manually generates test data or manually configures test simulators, and manually creates documentation of the created rule by way of natural language or the like.
An example of such a simple rule generation approach by means of a graphical user interface is for example described in Crossvision Product Documentation “The Graphical Rule Editor” by Software AG, which was accessible on Feb. 6, 2007 in the documentation section of the Software AG web site under the “webMethods” heading. The described rule editor is for rapid and cost-efficient creation, management and governance of new business processes. The graphical user interface for entering rules may be switched between three different views with different representations of the edited rule, i.e. diagram view, stylized English view and Flogic paraphrase view.
The implementation of a rule becomes more complex if the rule logic processes information contained in different events (e.g. event correlation). The splitting up of information over multiple events is necessary when the information is generated by different sources or at different moments in time. Furthermore, the requirement of Boolean logic between different conditions contributes to an increased rule complexity. This is for example the case in modern IT/IP (data) and communication networks consisting of a variety of different network elements from different vendors having different configurations, or providing a variety of different services of different categories and/or levels. Such a variety creates a situation where the same network requirement can be implemented in various ways. For a (network or service) monitoring tool this means that the monitoring rules need to be adaptable to the specific network conditions and/or services provided. A standard monitoring solution that would be locally developed by monitoring tool experts and then reapplied to all network elements is likely to fail or become extremely complicated in the majority of such cases.
The implementation of such complex rules in complex environments requires a high degree of flexibility that is hard to achieve with standard form-based user interfaces. Therefore, complex logic is often implemented by means of a programming language, e.g. as external scripts. For example, form-based interfaces for specifying threshold-based rules may be supplemented by external modules in programming languages such as Perl or C in order to implement more complex rule logic.
In this scenario, the rule development involves the typical steps and skills known from software development ignoring the fact that personnel that specify the rules are usually network administrators and not software developers. This problem has sought to be overcome by using skilled network administrators having software development background, or by the administrator writing a specification that is implemented by a separate software development teams (e.g. consultants or third party integration teams). Both approaches raise the costs of implementing a rule significantly as compared to the simple case where an administrator without programming skills can implement the rule. Furthermore, the risk of error increases with different people being involved in one rule implementation process.
Such a more advanced approach for rule generation is for example known from “Real-Time Monitoring and Operational Assistant System for Mobile Networks” by A. Rigallo, F. Verroca and A. L. String a, IEEE Network Operations and Management Symposium (NOMS) 2002, April 2002, Florence, Italy. This article is focused on network monitoring by means of a tool called “NetDoctor” based on JRules, which is a general framework for building rule engines by ILOG. That is, the described approach is directed to rule engine building on a general level without going into detail as regards how rules are generated. JRules is based on the RETE algorithm and allows defining rules with conditions and actions. The rules can be defined in a technical language, which is close to Java syntax. A less technical view to the rules may be provided by the so-called Business Action Language, where the rule has a textual representation. The tool focuses on the implementation of the business logic and does not provide an implementation of the rule actions, but leaves this to the business objects (implemented as Java objects). Also, this tool does not address the problems associated with generation of test data and documentation.
Another approach for rule generation is known from U.S. Pat. No. 5,917,489 which is directed to creating, editing and distributing rules for processing electronic messages. In the context of this patent, electronic messages include e-mail, meeting requests and task requests. Accordingly, the thus described approach is directed to hyperlink-based message processing (e.g. mail filtering in Microsoft® Outlook) rather than to more complex environments such as network or service monitoring. The document U.S. Pat. No. 5,917,489 describes a GUI-based rule wizard allowing the user to generate rules for message processing. The rule generation process is either done by a step-by-step guidance through various windows displaying options and/or variables for rule generation, or template-based by selecting one template as basis for the rule generation. The template used is either pre-defined or can be added by a system administrator. As the template is used as provided (without the ability to modify it as necessary), the described approach lacks flexibility in rule generation, thus only allowing generation of rather simple or precast rules.
Another drawback of the described approach resides in that the template used has options that depend on each other, which means that, if one option is selected, a number of other options can be selected. Therefore, there is required a GUI supporting dependant options, i.e. multiple successive windows with next/back buttons. Also, by way of this approach, rules are executed in a specific order. Thus, it is possible that a later rule in a rule list is never executed because an earlier rule prevents its execution, e.g. the e-mail to reach the latter (first-rule-wins strategy).
Another problem with known approaches for rule generation, including those mentioned above, relates to generation of test data and documentation, as already indicated above.
The more complex a rule becomes the more complex is also the testing of the rule. Test data needs to be generated that simulates all possible states of the rule's conditions and verifies the corresponding rule actions. However, there is no known available solution for this problem other than the manual creation of such test data, which is both cumbersome and error-prone.
The need for a clear rule documentation becomes more important with growing rule complexity and with the size of the network and its monitoring team or the variety of services provided in a network. If the rule is implemented using internal features of the monitoring tool, then the tool's own GUI can be used to explore and understand the rule logic. External rule implementations have limited support and require their own documentation, which is why internal solutions are preferable.
There are available a number of techniques for rule documentation and specification, for example textual descriptions, decision tables, or flow charts. The textual description, that describes a rule in an “if then” sentence is preferable because of its simplicity. However, there is no known solution for reliable rule documentation apart from the manual documentation by the rule creator.
However, information about the rule logic is contained not only in the implementation, but (if developed, i.e. manually by the rule creator) also in the test code and the rule documentation. Therefore, changing the logic requires changing all three development items individually (and manually), which is a further drawback of known approaches.
In view of the above, it is evident that known approaches for rule generation for rule-based (monitoring) systems exhibit several drawbacks in view of implementing complex (monitoring) rules in an easy and flexible way, preferably in a graphical manner, as well as generating rule code, test data, and rule documentation.
Thus, a solution to the above problems and drawbacks is needed for providing a rule generation for rule-based (network or service monitoring) systems in a complex environment.